Needs a rebase, conflicts should be relatively straightforward to fix

Can you explain some scenarios where we might want to have fs-verity disabled? Is it just on filesystems that can't support it? Because even without checking the verity data or anything, I find the "this inode is now immutable" thing to be extremely compelling, particularly in the presence of multiple hardlinks....

Can you explain some scenarios where we might want to have fs-verity disabled? Is it just on filesystems that can't support it?

That's by far the biggest case.

However, there is some generic overhead to having it...this isn't quite as relevant for bootc but it would be for taking fsverity in container runtimes in general. There are people that disable selinux to claw back like 1-2% of performance and fsverity is a bit like that, you just have this cost to paging in new code and doing cryptographic verification.

But supporting deploying to filesystems without it is 94.3% of the rationale for bootc.

Because even without checking the verity data or anything, I find the "this inode is now immutable" thing to be extremely compelling, particularly in the presence of multiple hardlinks....

Definitely! Before composefs existed I was trying to push for fsverity in ostree just for this reason...but I struggled with tying it to a higher level integrity story. Thankfully we have that now!

TODO: Also check for ostreedev/ostree#3354 - if that's set then we should key off it too.

In fact, maybe that should be the sole interface for now.